[レポート] DAT336: Aurora Serverless: コスト効率の高いアプリケーションのデプロイ #reinvent

大栗です。

現在re:Inventに来ています。こちらでAurora Serverlessのセッションに参加したのでレポートします。

Aurora Serverless: Scalable, Cost-Effective Application Deployment

[slideshare id=124113070&doc=aurora-serverless-scalable-co-e16ddc9c-9277-4d32-ae97-ab82fdceb6a9-94392281-181127014255]

RDSとAuroraの基本

Amazon RDSは、クラウドネイティブエンジンのAmazon Aurora、オープンソースエンジンのMySQL、MariaDB、PostgreSQL、商用エンジンのSQL Server、Oracleと様々なユースケースに対応できる。

Amazon Auroraはクラウドのために再設計されたデータベースで様々な特徴がある。

• ハイエンド商用データベースの速度と可用性
• オープンソースデータベースの簡素さとコスト効率
• MySQLとPostgreSQLの互換性
• シンプルな使っただけの料金
• 完全にマネージドなサービス

スケールアウト、分散、マルチテナント設計

• ログ構造の分散ストレージ
• 10GB単位で分散
• 6重化されたレプリカ、AZ当たり2個
• クォーラムでAZ＋1個か落ちても生き残る
• マスタと15個のリーダーが同じストレージを見る

Provisioned Auroraは、自分でマスタのサイズを決める必要がある

• ピークの負荷に合わせたサイズ
• 継続的な監視を行い、手動でスケールアップする

Aurora Serverless

Aurora Serverlessはアプリケーションに対して自動的に応答する。キャパシティのスケール、シャットダウン、起動が自動で行われる。

開発テストのワークロードの場合

ほとんどアイドル状態の開発テストのワークロードの場合

スパイクアクセスなゲームのワークロードの場合

ワークロードに合わせるにはいくつかの選択肢がある

• ピークに合わせたプロビジョン -> コストが高い
• ピークより少ないプロビジョン -> エンドユーザ（ビジネス）へ影響がある
• 継続的な監視と手動のスケールアップ/ダウン -> 難しい、エキスパートが必要になり、停止のリスクが有る

データベースのキャパシティ管理

• スケールアップのターゲットインスタンスの追加
• インスタンスのカットオーバー
• カットオーバーはダウンタイムを伴う可能性があり、カットオーバー後のバッファプールはコールド

• プロキシを追加してアプリケーションのコネクション変更を守る
• しかし、プロキシがSPOFになり、カットオーバー後のバッファプールがコールドなのは変わらない

Aurora Serverlessは

• アプリケーションの負荷に応じて自動で応答する
  • ダウンタイム無しでキャパシティがスケールする
  • マルチテナントのプロキシで高い可用性
  • スケールするターゲットはバッファプールが温まっている
  • 使っていないときはシャットダウンする

どう動いてるか

Aurora Serverlessは分散ストレージの上にMySQLのインスタンスが乗っており、マルチテナントのプロキシレイヤを経由してアクセスします。起動済みのAuroraインスタンスがプールされていて、動作しているインスタンスは監視サービスが見ています。

負荷が増えてきてCPU使用率やコネクション数が増加すると、起動済みループからインスタンスが取り出されて、バッファプールが移り、安全なスケールするポイントを見つけて、セッションの状態を移動します。

ワークロードがアイドルになるとゼロにスケールダウンします。

プロキシインスタンスが故障すると接続の一部だけに影響を受けます

負荷に応じて素早くスケールアップしたり、徐々に縮小

スケールアップイベントごとにレイテンシが急速に低下する

初期のスパイクの後に負荷が高くなってもレイテンシは迅速に安定します

新機能

RDSのデータAPIの紹介

• データベースアクセスのためのシンプルなWebサービスプロトコル
• HTTPリクエストとしてパッケージ化されたSQL
• AWS LambdaとAWS AppSyncからデータベースにアクセスできる
• AWS SDKとCLIからデータベースにアクセスできる

RDSコンソールのクエリエディタの紹介

• マネージメントコンソールからデータベースにアクセスできる
• データベースクライアントアプリケーションやターミナルが不要

PostgreSQL互換のAurora Serverless

• 現在Preview中

Aurora Serverlessの利用可能なリージョンが増加

• ソウル
• シンガポール
• シドニー
• ムンバイ
• 北カルフォルニア
• ロンドン、パリ
• フランクフルト
• カナダ中央

ケーススタディ - Pagely

WordPressホスティングサービスを提供するPagelyではNorthstackというサーバーレスなアプリケーションホスティングを提供しています。

• コンピュートはECS
• Appゲートウェイとワーカーは停止可能
• 各本番アプリは自身のAurora Serverlessがある
• キャッシュ可能なサイトではゲートウェイのみが実行される

エラスティックなデータベースは難しい

• WordPressで書き込み後に読み込むとスレーブの有用性が制限される
• シングルテナントオプションとマルチテナントオプション

Aurora Serverlessは完全にフィット

• マスタがスケールする
• ダウンタイム無しのスケール
• 自分のチームからの仕事が減る
• 停止

注意点として

• 休止から再開する時間は一貫性がない
• オーロラにはスケールする場所が必要
• MySQL server has gone away エラー

休止時間の管理

• 一番のコスト削減は休止
• 再開は時間差が大きい

WordPressのスロークエリの話

• meta_valueテーブルのフルスキャンは一般的
• 2ACUではクエリは10分かかる
• 8ACUではクエリは2秒未満

オーロラにはスケールする場所が必要

• クエリのタイムアウトを追加
• グローバルタイムアウトに注意
• いつも簡単ではない
• MySQL 5.7でSET SESSION MAX_EXECUTION_TIME=2000;
• Sysown Proxysqlのmysql-default_query_timeout
• mysqlndを使ったPHPでmysqlnd.net_read_timeout

MySQL server has gone away エラー

• Aurora Serverlessでは極めて一般的
• タイムアウトの発生が増える
• 可能であれば自動再接続を有効化
• WordPressのカスタムDBドライバがキャッチして再接続
• SysownのProxySQL

さいごに

今までAurora Serverlessが動的にスケール変更を行う時にダウンタイムやセッションの維持が気になっていたのですが、上手くコンテナ間で移動させていることが分かりました。

またPagelyの例で気をつけるべき点も分かり良いセッションでした。